Renames the abxpkg-managed shim dir from <install_root>/shims to
<install_root>/bin so ScoopProvider follows the same bin_dir
convention as brew / cargo / gem / etc. Scoop's native auto-generated
shim dir (<install_root>/shims/) stays on PATH so scoop-installed
binaries are still resolvable, and <install_root>/apps remains as
a last-resort lookup for the raw .exe paths.

Addresses review feedback from @pirate on PR #31.

…ovider, not BinProvider

ty-check / pyright caught that _link_loaded_binary is defined on
EnvProvider (binprovider.py:2576), not the BinProvider base
class that ScoopProvider extends. Replace the call with a direct
link_binary(...) invocation (the same low-level helper
_link_loaded_binary itself uses).

…r tests on Windows

The pytest_ignore_collect hook I added last round doesn't fire for
paths passed explicitly on the command line (pytest bypasses it for
initpaths — which is exactly how the CI per-file jobs invoke
pytest). As a result the Unix-only provider tests were still being
collected and FAILing on Windows.

Switch to pytest_collection_modifyitems which runs after collection
regardless of how items got there. On Windows we tag every item in
test_{apt,brew,nix,bash,ansible,pyinfra,docker}provider.py with a
pytest.mark.skip(reason=...) so they report as skipped (exit 0)
instead of failing.

gem is in UNIX_ONLY_PROVIDER_NAMES on Windows so per-file
test_gemprovider.py is already skipped by conftest. This
cross-provider test_real_installs_land_under_abxpkg_lib_dir
test invokes GemProvider.install(...) directly, bypassing the
conftest filter, so gate the gem portion of its inline subprocess
script behind sys.platform != 'win32' and drop the
require_tool('gem') precondition on Windows.

The inline script's gem portion is gated on Windows but the
post-script assertion loop still unconditionally expected a gem
key in the returned payload — triggering KeyError: 'gem'. Match
the script-side guard here so the loop only looks for gem when
the script ran its gem install.

…t on Windows

Third location that hardcoded gem into the expected state: the
final issubset(top_level_subdirs) sanity check at the bottom of
test_real_installs_land_under_abxpkg_lib_dir still listed gem
even though gem is no longer installed under Windows. Wrap it with
the same if not IS_WINDOWS guard.

…em access

Fixes pyright/ty reportOptionalMemberAccess / unresolved-attribute
that my previous patch introduced — the reloaded.loaded_abspath
type is Path | None so accessing .parent/.stem without
an explicit is not None assert flags as potentially unbound.

…s test

Mirror the test_bunprovider fix: gifsicle.cmd on Windows
reports the missing-vendor-binary error to stderr but still returns
exit 0 (unlike POSIX shells which propagate). Accept either signal.

…brew, uv tool shim

- test_pnpmprovider.py::test_install_args_win_for_ignore_scripts_and_min_release_age:
  same pattern as npm/bun — Windows .cmd wrappers return 0 for the
  --ignore-scripts postinstall-missing case but emit the is not
  recognized error to stderr. Accept either signal.
- test_security_controls.py::test_nullable_provider_security_fields_resolve_before_handlers_run:
  skip the BrewProvider leg on Windows (brew is in
  UNIX_ONLY_PROVIDER_NAMES there and its INSTALLER_BINARY lookup
  raises BinProviderUnavailableError on hosts without brew, which
  is unrelated to what this security-field test is verifying).
- test_uvprovider.py::test_global_tool_mode_can_load_and_uninstall_without_bin_shim:
  hardcoded tool_bin_dir / 'cowsay' misses the Windows
  cowsay.exe shim. Resolve via bin_abspath which honors
  PATHEXT so both POSIX and Windows layouts match.

Previously the Windows matrix deliberately skipped Yarn Berry because
the Unix setup uses ln -sf / homebrew prefix dirs that don't
translate. The side effect was every test_yarnprovider.py test
that uses require_tool('yarn-berry') bailed out with
AssertionError: Could not resolve the globally installed yarn-berry
alias on PATH on Windows.

Add a Windows-specific Berry setup step that uses git-bash + npm:
- npm install --prefix %USERPROFILE%/yarn-berry @yarnpkg/cli-dist@4.13.0
- write a tiny yarn-berry.cmd wrapper that forwards to the
  npm-installed yarn.cmd (no ln needed).
- stage the wrapper dir onto GITHUB_PATH so shutil.which finds it.

Matches the Unix behavior (yarn classic + Berry both on PATH) so the
yarnprovider Windows test suite can actually run.

…run-update test

Fixes two Windows-only CLI regressions:

- UnicodeEncodeError: 'charmap' codec can't encode character
  '\U0001f30d' — Windows console stdout defaults to the ANSI code
  page (cp1252) which can't encode the emoji / box-drawing
  characters abxpkg prints (🌍, 📦, —, …). Added _force_utf8_stdio
  which reconfigure()s sys.stdout / sys.stderr to UTF-8
  (with errors='replace' as belt-and-suspenders), wired into both
  main() and abx_main() entrypoints. Unix stdio is already
  UTF-8 so this is a no-op there. Fixes
  test_abxpkg_version_runs_without_error and
  test_version_report_includes_provider_local_cached_binary_list.
- test_run_update_skips_env_for_the_update_step: the hardcoded
  Path("/tmp/fake-bin") literal stringifies differently on Windows
  (\tmp\fake-bin) vs POSIX. Use tmp_path / 'fake-bin' on both
  sides of the assertion so the comparison holds on every platform.

Playwright's --with-deps is a Linux apt-get-based dependency
installer (and a macOS no-op). On Windows it's flat-out unsupported —
Playwright prints a hard warning and ignores the flag. That warning
pollutes our install log parser. Gate the flag on not IS_WINDOWS
so the Windows install invocation stays clean.

npm.cmd on Windows is a batch wrapper; Python's subprocess
ultimately invokes it through cmd.exe which treats > / <
as redirect metacharacters. Passing zx@>=8.8.0 as an argv item
gets shell-eaten to zx@ (with cmd.exe writing stdout into a
file named =8.8.0), so the version pin is silently dropped and
npm just reuses the already-installed zx@7.2.x, failing the
subsequent min_version revalidation.

Use npm's ^X.Y.Z caret range on Windows — semantically equivalent
>=X.Y.Z, <X+1.0.0 upgrade range, no shell metacharacters.
Applied in both default_install_handler (line 404) and
default_update_handler (line 467).

The previous commit's inline heredoc put @echo off at column 1,
which YAML tries to parse as the start of a token @ is a reserved
indicator). GitHub Actions rejected the whole workflow as
malformed, making every test job skip.

Replace the heredoc with a single printf call that keeps the
body inside the YAML block-scalar's indentation — functionally
equivalent but parseable.

…installed via --with-deps on Windows)

Corrected my earlier claim: playwright install --with-deps on
Windows actually DOES install the Visual C++ 2015-2019 Redistributable
(Playwright registry/dependencies.ts has explicit Windows handling for
it). That's exactly the runtime chromium.exe needs to load without
the WinError 14001 side-by-side configuration is incorrect error.

Always emit --with-deps; update the docstring to reflect the
actual per-OS behavior.

….cmd

Previous setup called command -v yarn-berry / yarn-berry --version
after creating yarn-berry.cmd. git-bash's command -v doesn't
consult PATHEXT so it couldn't find the .cmd shim, failing
the whole Setup step with exit code 1 before any tests could run.

Invoke the .cmd file directly for the build-time version check,
and rely on GITHUB_PATH export for subsequent steps (pytest /
shutil.which on Windows does honor PATHEXT).

The abxpkg / abx CLI entrypoints call _force_utf8_stdio
so they can emit the 🌍 / 📦 / etc. banner emojis without hitting
cp1252 UnicodeEncodeError on Windows. The test harness's
subprocess.run(capture_output=True, text=True) in _run_cli
was still decoding the captured output with the parent's
locale.getpreferredencoding() (cp1252 on Windows runners),
which fails on emoji bytes — Python 3.13 silently sets the
corresponding stream to None on the returned CompletedProcess,
causing every test that does "X" in proc.stderr to raise
TypeError: argument of type 'NoneType' is not iterable.

Pin encoding='utf-8', errors='replace' so the parent decode matches
what the child emits regardless of OS locale.

…xS dep)

GitHub's windows-latest is Windows Server 2025 which ships
WITHOUT the Media Feature Pack (a server-SKU optional feature).
Chromium binaries bundled by Playwright / Puppeteer reference
mf.dll / mfplat.dll etc. in their SxS manifests, so running
chrome.exe --version after install fails with
WinError 14001 side-by-side configuration is incorrect even
though playwright install --with-deps successfully installs
the Visual C++ Redistributable.

Add Add-WindowsCapability step via pwsh to install the Media
Feature Pack before provider tests run. Silently skips if already
installed or unavailable.

…romium runtime); tests: portable temp dir + cmd shim

Windows Chromium SxS:
- Windows Server 2025 ships WITHOUT the Media Foundation role (consumer
  Windows has the Media Feature Pack capability, Server has the
  Server-Media-Foundation role). Chromium's chrome.exe SxS
  manifest references mf.dll / mfplat.dll from that role. Add
  Install-WindowsFeature -Name Server-Media-Foundation to the
  Windows setup step so Playwright / Puppeteer chromium binaries can
  actually launch after install.
- Also choco install vcredist140 as belt-and-suspenders; Playwright's
  own --with-deps VC++ install is best-effort on some versions.

Test portability:
- test_run_stdout_stderr_are_separated_and_not_buffered: write a
  .cmd batch shim on Windows (previously only a #!/bin/sh POSIX
  shim — Windows can't execute that without a shell interpreter). Use
  os.pathsep for the PATH env override too.
- abx_e2e_lib fixture: swap the hardcoded /tmp/abx-e2e-lib
  literal for tempfile.gettempdir()/abx-e2e-lib so the Windows
  runner's temp dir is used instead of C:\tmp.

Previously-pushed batch of Windows fixes picked up a formatter
diff on CI that wasn't present locally — apply it now.

… path

Previous attempt copied npm's yarn.cmd to a new dir, but that
launcher uses %~dp0 (its own dir) to resolve yarn.js via a
relative ..\@yarnpkg\cli-dist\bin\yarn.js path. After copy,
%~dp0 points to the NEW dir and the relative resolution fails
(Cannot find module 'C:\Users\runneradmin\@yarnpkg\...).

Build the wrapper by hand: node <absolute-yarn-js-path> %*. The
JS entrypoint's location is stable, so the shim works from any dir.

…rectly

The node_modules/.bin/yarn file npm installs is a POSIX shell
script, not a JS file — node <that> fails with a SyntaxError
(missing ) after argument list). Point the wrapper straight at
@yarnpkg/cli-dist/bin/yarn.js, which is the actual JS entrypoint.

The Server-Media-Foundation install step was piping through Out-Null
so its result status wasn't visible. Dump it to Host so we can see
whether the feature actually installed. Also install vcredist2013
(some chromium-bundled components reference the older MSVCR120.dll)
alongside vcredist140. Verify System32 DLLs (mf.dll, mfplat.dll,
vcruntime140.dll) at the end of the step so we can diagnose what's
still missing from the SxS manifest.

…fallback

pip show's stdout is occasionally truncated mid-stream on Windows when
forwarded through abxpkg's capture_output=False subprocess pipe
(Python subprocess pipe + Windows text-mode line translation quirk
— reproduces only with pip, not other console scripts). Sometimes
the Location: line doesn't make it through, so fall back to
verifying black was installed into the managed venv by globbing
for its black-*.dist-info directory under
<tmp_path>/pip/venv/*/site-packages/. Same guarantee — the
PipProvider's isolated venv is what ran pip install — without
depending on flaky stdout forwarding.

- yarn/pnpm provider: use @^X.Y.Z range (not @>=X.Y.Z) on Windows.
  Same root cause as the earlier npm fix — yarn.cmd / pnpm.cmd go
  through cmd.exe, which treats ``>`` as a stdout redirect and
  trims ``zx@>=8.8.0`` down to ``zx@`` (eating the version floor).
  ^X.Y.Z has identical upgrade semantics without the metacharacter.

- CI Windows yarn-berry.cmd: rewrite as a ``call`` forwarder to
  ``<prefix>\\node_modules\\.bin\\yarn.cmd`` (the real Yarn 4 shim
  npm installs). ``%~dp0`` inside that shim now resolves relative
  to its original dir, so yarn.js lookup works. Critically, the
  ``node_modules\\.bin`` dir is NOT added to PATH — keeping the
  globally-installed Yarn 1.x ``yarn.cmd`` visible for classic
  tests.

- test_yarnprovider: parse the ``yarn-berry.cmd`` forwarder to
  recover ``berry_bin_dir`` on Windows (readlink doesn't apply to
  a ``.cmd`` file); use ``os.pathsep`` consistently instead of
  hardcoded ``:``.

…fixes

- test_puppeteerprovider / test_playwrightprovider: when ``link_binary``
  appends ``.exe`` to the managed shim name on Windows, the resulting
  path is ``bin_dir/chromium.exe`` (or ``chrome.exe`` for chromium),
  not ``bin_dir/chromium``. Compare against the expected platform-
  specific shim name instead of asserting the bare stem.

- puppeteer ``_parse_installed_browser_path``: the ``re.MULTILINE``
  pattern's ``$`` doesn't consume ``\r`` in a ``\r\n`` terminator, so
  on Windows the trailing ``\r`` gets captured into ``path`` and
  ``Path("C:\\...\\chrome.exe\r").exists()`` is False. Switch the
  path group to ``[^\r\n]+?`` with trailing ``\s*`` to strip both.

- conftest ``command_version``: force UTF-8 decode on subprocess
  output so emoji / non-cp1252 ``--version`` text doesn't crash the
  test with UnicodeDecodeError on Windows.